home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ 12⁄31⁄89 / 0270-Guerilla MacApp?-Dec89 < prev    next >
Encoding:
Text File  |  1990-01-02  |  2.4 KB  |  52 lines  |  [TEXT/GEOL]
  1. Item    5585844                         26-Dec-89        22:47
  2.  
  3. From:   D5295                           Reseach SW Design, D Goldman,PRT
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.  
  7. Sub:    Guerilla MacApp?
  8.  
  9. Reviewing the past couple months' archives, I'm struck by the number of threads
  10. which begin "I'm trying to get the following behavior..." and then receive
  11. several separate replies saying "Here's some code that worked for me..." How
  12. many wheels are we reinventing how many times here, anyway?
  13.  
  14. Then there are all the "It would be much nicer if this piece of MacApp worked
  15. like this..." messages. (For example, see my own link about the desirability of
  16. TTEView implementing the full Human Interface Guidelines for text editing.)
  17. Occasionally somebody from Apple replies "Good idea; we'll implement that in
  18. the next version." But usually they don't, either because they disagree (in
  19. which case they often say so), or more likely because they're much too busy
  20. stamping out bugs and coping with System 7.0 and who knows what else.
  21.  
  22. Why don't we (the developers) form ad hoc working groups on individual areas of
  23. concern? A few of us could send code back and forth until we were all
  24. satisfied, and then post the results on AppleLink. One advantage of OOP is
  25. supposed to be the ability to create new classes for use by others, right? (For
  26. example, how would you like a subclass of TTEView which handled the full H.I.
  27. Guidelines?)
  28.  
  29. (One of Apple's MacApp developers could even take a look at the code we produce
  30. -- to point out overlooked stuff, to endorse it, or to incorporate it into the
  31. next MacApp release. While desirable, though, this is certainly not required.)
  32.  
  33. Given the current level of code-sharing on MacApp.Tech$, I don't see any new
  34. trade secret or copyright issues arising here. Once posted, any code would
  35. enter the public domain.
  36.  
  37. I guess the bottom line is: Instead of whining to Apple about changes we would
  38. like to see in MacApp, and instead of reimplementing the same thing a dozen
  39. times, why don't we collectively (and carefully) produce the needed
  40. enhancements (hopefully as overrides, not rewrites) ourselves, and then post
  41. them on a publicly-accessible board?
  42.  
  43.  
  44. -- Dave Goldman
  45.  
  46.  
  47. (P.S. Maybe MADA should have a role in this?)
  48.  
  49. (P.P.S. Despite the title I think I'll give this when I post it, this is not
  50. intended as some sort of subversive, anti-standardization proposal.)
  51.  
  52.